• This really is just a convention and nothing precludes using = instead of <- for assignment

• When mixed, <- has precedence over =

• Fact: <- comes from a time where there actually was a <- key on keyboards. <- and -> essentially do the same thing.

• R interprets a <- b = 1 as '<-<-'(a, b = 1, value = 1)

• -> is the right-assignment operator

• The precedence relation is -> >> <- >> = so x <- 1 -> b is another working alternative to the last line on the previous slide.

• Note that functions generate their own environments upon execution. The execution environment of a() is the parent environment to b().

• If <<- does not find a corresponding binding in the enclosing environment, it looks in the parent environment and works it's way up towards to global environment (GE)

• If the binding does not exist in the GE, it will be created there

• This is very different for many other languages, including c++ which we will see later during the course.

• Question: object addresses (like 0x7f9ef3059d38) will be different (unpredictable) if the code is re-run. Why?

Simply put, a call stack describes the order of nested function calls.

No copy because z is just a reference to the value of x.

• f(x): f() binds a to the same memory location x points to during execution. In Contrast to the previous slide, a copy is made since f() modifies a.

• z<-f(x): as above. z is a binding the same location as a (no additional copy made).

• Q: What would happen if we'd super assign to x inside of f()? A: no additional reference to x, so calling f() would not trigger a copy.

l1 <- list(1, 2, 3)    # left
l2 <- l1               # right
l2[[3]] <- 4           # bottom

Note that copy-on-modify due to l2[[3]] <- 4 results in a shallow copy: the bindings are copied, not the values. ⇒ performance considerations!

A: modifying a single row implicates modifying all columns (this cannot be tracked by tracemem() but can be seen using lobstr::ref())

df[1, ] <- c(42, 42)
ref(d1)
# vs.
df$x <- c(7, 7, 7)
ref(d1)

1. 1:10 is no binding so there's no point in tracing a value.

2. Here x is an integer vector (x has double type as defined on Slide 11). Replacing 3L with 4, i.e. integer with double, triggers coercion of x to double. This always results in a copy.

3. : is special in the sense that it generates integer sequences using only the first and the last element. The number of elements thus doesn't affect the required memory.

• Q: Running this code in RStudio will trigger a copy. Why?

  A: An entry in the Environment tab is a binding, i.e., there are more than one (two) references to v which triggers a copy!

  You need to run the code in the GUI version of R for reproducing the results.

  (using the R-GUI for this purpose is generally a good practice!)

• Note that tracemem() does not play well with knitr

• Note that vapply()'s FUN.VALUE requires a template for the return value (which is numeric $1\times 1$ here)

• We will come back to consequences of this behavior in the Chapter Improving Performance and benchmark against alternatives that require less copies.

Using the $ operator makes no difference: $<- also has a $<-.data.frame method. The output of tracemem() then looks similar to this:

tracemem[0x7fe515db8d88 -> 0x7fe513bcd788]: 
tracemem[0x7fe513bcd788 -> 0x7fe513b79a88]: $<-.data.frame $<- 
tracemem[0x7fe513b79a88 -> 0x7fe513b79c88]: $<-.data.frame $<-

• The two copies made by [[<-.data.frame are shallow copies (only column references are copied)

• Q to students: What kind of function is [[<-.data.frame?

  A: A regular function. It is a method of [[<- which is a primitive (a fast C function)

• Q to students: How can you view the source?

  A: `[[<-.data.frame`

• More on primitives on the next slides. More on methods, dispatch etc. in the 'OOP' Chapter.

• More on how to write efficient code (and especially efficient for() loops) in Chapter 'Improving Performance'

• A single copy is made from internal C code the first time we use [[<-

• This a good example where tweaking the code reduces the amount of copies made

• If such a solution is not readily at hand we may resort to C++ code. More on this in the Rcpp chapter.

• x is assigned to itself (an additional reference) so a copy on modification is made

• The the old memory location of x has no binding anymore but is referenced within x

• Note that lists are always copied on modification. The copy is, however, shallow .

(b) stresses why it's wrong to think of x to 'store' anything different than an address.

• The only reason to call gc() is if you need to free-up memory for your operating system — which will hardly ever happen

• vcells = memory used by vectors; ncells = memory used by anything else

• The 'large numbers' report cells used (8 byte each)

• lobstr::mem_used() does not agree with what's reported by your OS: there are other objects (generated by, e.g., the R interpreter) which are not captured

Obviously, R functions are objects on their own right — they need not be bound to a name!

• ( is a primitive:

  `(`

  ## .Primitive("(")

• The R-help hints that ( is semantically equivalent to function(x) x.

  E.g., (x<-5) is valid (and useful) R code!

rm(x)
z <- function(x) x^2
# 3. everything in f() happens in an ephemeral environment
f <- function(g) {       
    if(!exists("x")) {   
        x <- 1
    } else {
        x <- x + 1
    }
    z <- 2               # 1. name masking
    z(x + y)             # 2. functions before variables
}
y <- 20
f(x)                     # 4. dynamic lookup

## [1] 441

• Explanation: f() evaluates its argument x when it's needed: at runtime, y<-5 is bound outside of f() in the GE. Once x+1 needs to be computed, y<-6 is evaluated (which overwrites y in GE).

• Loading a data set using data() uses a promise. See, e.g., data(AirPassengers).

• The style shown in the example used by many base R function but it's not recommended since its hard to understand what's going on.

We see that double(20) is evaluated only once: there's only one message printed. This is when c() inside of clone() looks for x for the first time.

• Although we do not recommend this style, it reflects great flexibility due to lazy evaluation

• Note that this approach may be useful when a default argument is computationally expensive to evaluate and not needed in every call to f() (this usually happens when the argument is a more complex function call than '+'())

• Due to lazy evaluation, the evaluation environment for default arguments is the function environment

• User supplied arguments are evaluated in the parent environment (GE here)

• NULL represents the null object in R. NULL is used mainly to represent a list with zero length, and is often returned by expressions and functions whose value is undefined.

• Without lazy evaluation this statement would throw an error because x > 0 evaluates to a logical value of length zero (you cannot compare NULL to double)

• Control flow stops after evaluating the first part of the condition in if(): the second statement would be evaluated only if the first is TRUE (here it is FALSE)

1. Lazy evaluation happens at function definition, not invocation: R looks for z in the global environment because x is not z^2 by default, like in the fixed version below.

   f <- function(x = z^2, z) {
     z + x^2
   }
   f(2, 2)

   Workaround using with:

   with(list(z = 2), f(x = z^2, z))

2. ... enables us to pass arguments the body of f() (to other functions!) which do not have to be specified at definition of f().

   Here, f() is a simple wrapper that returns names of list elements as passed to the ... argument.

• @infix forms: user defined operators (which always begin and end with %) belong to this class.

• NB: is doesn't matter whether one uses `` or '' in prefix form

• Note that replacement functions must have x and value as arguments and return the modified object x

• Additional arguments may be passed between x and value

tracemem() reports two copies: the first occurs because last<- creates a copy inside its own environment before modification and R runs

x <- `last<-`(x, 420)

under the hood.